Mobile Internet Protocol (IP) is a protocol that provides routing of IP datagrams to a mobile node (MN) as it travels through the Internet. The MN has a home IP address, which is used when the MN is located within a home domain. The home domain provides a subscription and a home address (HoA) to the MN. When the MN is located outside of the home domain, it acquires a care-of address from a visited domain. The MN informs the home domain of the care-of address allocated thereto by the visited domain in a so-called binding process. When a packet or datagram is received in the home domain identifying the HoA as a destination, while the MN is known to be roaming in the visited domain, the home domain forwards the packet towards the MN in a tunnel, with the care-of address as a new destination address. Mobile IP requires that the MN be capable of detecting whether it is located in the home or in a visited network, and acquiring a care-of address.
Using Mobile IP, MNs may connect to other nodes, usually referred to as correspondent nodes (CN). FIG. 1 shows a Mobile IP network architecture as described in the Mobile IP version 6 (MIPv6) specification found in an Internet Engineering Task Force (IETF)'s Request For Comment (RFC) number 3775, entitled “Mobility Support in IPv6”, incorporated herein by reference. As can be seen in FIG. 1, an IP network 100 comprises a MN 110 in communication with a CN 120 on a link 122. The link 122 is unlikely to be composed of only one direct physical connection, but rather represents a series of links between routing equipments transparently enabling the communication therebetween. The way the series of links is used to transport traffic between the MN 110 and the CN 120 is irrelevant to the present description, as long as IP communication therebetween can be established.
The MN 110 has a permanently assigned HoA valid in a home network 127, which HoA is allocated upon initialization of the MN 110 in the home network 127. The allocation mechanism is well known in the art. The MN 110 is further in communication with a home agent (HA) 130 located in its home network 127. Among other functionalities, the HA 130 keeps a record of a foreign address of the MN 110 valid outside the home network 127. The foreign address is called care-of-address (CoA) in the context of MIPv6. The CoA assigned to the MN 110 changes in time as the MN 110 moves from one network to another. A record kept by the HA 130, referred to as binding in the context of MIPv6, ties the CoA to the HoA. A binding between the HoA and the CoA is also kept in the CN 120 for the purpose of reaching the MN 110. The HA 130 is also responsible for routing traffic received at the HoA to the MN 110. The received traffic is forwarded by the HA 120 on a link 125 toward the MN 110. It should be noted that the MN 110 may have multiple home and care-of addresses, and that a binding should be kept at the HA 130 for each HoA-CoA pair.
Following now is an example of how the MIPv6 concept applies in a typical situation. For the benefit of the example, the MN 110 is in bidirectional IP communication with the CN 120 on the link 122. When the MN 110 moves from a first network to another, as illustrated by an arrow 135 on FIG. 1, the MN 110 receives a new CoA. This modification in addressing state of the MN 110 must be advertised to the CN 120 and to the HA 130. Prior to the advertisement, the MN 110 must first make sure that the HoA, which did not change, is still valid and that the newly acquired CoA address is usable to communicate with the CN 120. This assessment is done via a return routability (RR) test or procedure. The RR procedure also allows the creation of an authentication key, used to ensure that the advertisement procedure is made under trust between communicating parties. For this purpose, a care-of init cookie and a home init cookie are built by the MN 110, also protecting the RR procedure from being maliciously intercepted or interfered by a third party.
The RR procedure starts at the MN 110, which sends a home test init (HoTI) message through the HA 130, on the link 125, using its HoA as a source address. The HoTI message contains the home test init cookie and is addressed to the CN 120. Upon reception of the HoTI message, the HA 130 forwards it to the CN 120 on a link 140. The link 140 has similar characteristics as the link 122. Simultaneously to sending the HoTI message, the MN 110 sends a care-of test init (CoTI) message containing the care-of init cookie toward the CN 120 on the link 122, with its new CoA as the source address.
Upon reception of the CoTI message, the CN 120 replies with a care-of test (CoT) message addressed to the source address of the CoTI message, which is in the case the new CoA of the MN 110, on the link 122. The CoT message contains the care-of init cookie and a care-of keygen token generated by the CN 120. Upon reception of the HoTI message, the CN 120 replies with a home test (HoT) message addressed to the source address of the HoTI message, which is the HoA of the MN 110, on the link 140. The HoT message contains the home init cookie and a home keygen token generated by the CN 120. Reception of the CoT and HoT messages at the MN 110 successfully completes the RR procedure. The MN 110 keeps the content of both the HoT and CoT messages and then continues with the advertisement of the modification of its CoA toward the CN 120 and the HA 130.
In order to advertise any modification to its CoA, the MN 110 sends a first binding update (BU) message to the HA 130 on the link 125 containing the newly acquired CoA and other information related to the HA 130 binding. The HA 130 then updates its corresponding binding and replies to the MN 110 with a first binding acknowledgment (BA) indicating the successful update of the binding. The MN 110, after sending the first BU, uses the care-of keygen token and the home keygen token received earlier from the CN 120 to generate an authentication key valid between the MN 110 and the CN. The authentication key is commonly referred to as binding management key (Kbm) in the context of MIPv6. The MN 110 then creates a second BU similar to the first BU, signs it with the authentication key and sends it to the CN 120 on the link 122. The CN 120, upon reception of the second BU or before, generates the same authentication key using the tokens it already generated and further verifies the received second BU before updating its own related bindings. The CN 120 then creates a second BA, signs it using the authentication key and sends it, in accordance with the MIPv6 specification, on the link 122, addressed to the MN 110. Reception of the second BA at the MN 110 indicates the successful completion of the advertisement of the modification.
Many devices, such as laptops or personal assistants, may be moved by their users, but do not have the above described capabilities. Alternatively, the user of a mobile device may elect to disable its Mobile IP capability, for example to reduce signaling on a wireless link between the mobile device and an access point of a visited domain.
Proxy Mobile IP (PMIP) provides mobility capabilities to MNs that do not support mobility as defined in the MIPv6 specification. With PMIP, the MN does not need to support any mobility related signaling. Mobility features are solely supported by the network. The care-of address that was assigned by a visited network to the MN, in Mobile IP, is replaced in PMIP by a proxy care-of address (pCoA). The pCoA is the address of a gateway that provides connectivity to the MN. A description of PMIP is made in RFC 5213, entitled “Proxy Mobile IPv6”, from the IETF, incorporated herein by reference.
FIG. 2 (Prior Art) shows a Proxy Mobile IP (PMIP) network 200, consistent with PMIP RFC 5213. The network 200 comprises three subnetworks owned by three distinct operators A, B and C. An access network 210 of operator A comprises a local mobility anchor (LMA) 220, sometimes called local mobility agent, and two media access gateways (MAG) MAG1 and MAG2, which are also sometimes referred to as proxy mobile agents. The LMA and MAGs provide PMIP support to MNs. Mobile nodes, for example MN1, MN3 and MN2, are subscribed in the subnetworks of operators B and/or C, but are currently located within the access network 210 of operator A. The LMA is used within operator A's subnetwork to manage local mobility. In an exemplary fashion, MN1 and MN3 are connected to MAG1 and MN2 is connected to MAG2. The MNs may be connected to the MAGs directly or through access points (not shown), which may be wireless access points. Of course, those skilled in the art will recognize that the subnetworks of each operator may comprise a plurality of MAGs and LMAs. Also, the subnetworks would comprise supplementary nodes such as routers, home agents, foreign agents, authentication servers, databases, and the like. Those supplementary nodes are not depicted in FIG. 2 for ease of the description of the problems present in the prior art.
When a given MN attaches to a domain that supports PMIP, it sends an access request, possibly through an access point. The access request arrives at a MAG. The MAG sends information about the access request to the LMA in a Proxy Binding Update (PBU) message. The access request may also be forwarded from the MAG to an authentication server (not shown) for authentication and profile retrieval. The PBU comprises an address of the MAG, called proxy care-of address (pCoA), to be used as a care-of address of the MN. The LMA stores in a binding cache the pCoA with a home network prefix (HNP) of the MN. The LMA replies to the MAG with a proxy binding acknowledgement (PBA) message carrying the HNP of the MN. Having received the PBA, the MAG advertises the HNP on a link to the MN. This makes the MN act as if it was connected on a home link, and the MN uses the HNP to configure for itself a HoA. If the MN is roaming, implying that the LMA is not part of the home domain for the MN, the LMA builds a regional care-of address (rCoA) and sends the rCoA to the home domain of the MN, thereby making the home domain forward traffic intended to the MN as per the Mobile IP protocol. In a first global mobility process, a packet intended for the MN is sent from the home domain through the LMA by use of the rCoA. Then, in a second local mobility process, the LMA encapsulates this packet and tunnels it to the MAG by use of the pCoA. The MAG receives this packet, decapsulates it, and sends it to the MN. Packets originating from the MN are sent through the MAG to the LMA and then to their destination addresses.
The RFC 5213 that defines PMIP requires that all traffic exchanged between the CN and the MN be tunneled between the MAG and the LMA. That specification does not allow any route optimization; in fact, the specification expressly states that the RR procedure defined in the RFC 3775 is not applicable under PMIP. When the MN is in communication with a CN located outside of the MN's PMIP domain, this tunneling is highly inefficient because it neither accounts for the respective locations of the MN and the CN nor benefits from potential high bandwidth links that may be available between the MN and the CN.